Streaming media delivery may become increasingly important as it becomes more common for high quality audio and video to be delivered over packet-based networks, such as the Internet, cellular and wireless networks, powerline networks, and other types of networks. The quality with which the delivered streaming media can be presented may depend on a number of factors, including the resolution (or other attributes) of the original content, the encoding quality of the original content, the capabilities of the receiving devices to decode and present the media, timeliness and quality of the signal received at the receivers, etc. To create a perceived good streaming media experience, transport and timeliness of the signal received at receivers may be especially important. Good transport may provide fidelity of the stream received at the receiver relative to what a sender sends, while timeliness may represent how quickly a receiver can start playing out the content after an initial request for that content.
A media delivery system can be characterized as a system having media sources, media destinations, and channels (in time and/or space) separating sources and destinations. Typically, a source includes a transmitter with access to media in electronically manageable form, and a receiver with an ability to electronically control receipt of the media (or an approximation thereof) and provide it to a media consumer (e.g., a user having a display device coupled in some way to the receiver, a storage device or element, another channel, etc.).
While many variations are possible, in a common example, a media delivery system has one or more servers that have access to media content in electronic form, and one or more client systems or devices make requests for media to the servers, and the servers convey the media using a transmitter as part of the server, transmitting to a receiver at the client so that the received media can be consumed by the client in some way. In a simple example, there is one server and one client, for a given request and response, but that need not be the case.
Traditionally, media delivery systems may be characterized into either a “download” model or “streaming” model. The “download” model might be characterized by timing independence between the delivery of the media data and the playout of the media to the user or recipient device.
As an example, media is downloaded for enough in advance of when it is needed or will be used and when it is used, as much as is needed is already available at the recipient. Delivery in the download context is often performed using a file transport protocol, such as HTTP, FTP or File Delivery over Unidirectional Transport (FLUTE) and the delivery rate might be determined by an underlying flow and/or congestion control protocol, such as TCP/IP. The operation of the flow or congestion control protocol may be independent of the playout of the media to the user or destination device, which may take place concurrently with the download or at some other time.
The “streaming” mode might be characterized by a tight coupling between the timing of the delivery of the media data and the playout of the media to the user or recipient device. Delivery in this context is often performed using a streaming protocol, such as the Real Time Streaming Protocol (RTSP) for control and the Real Time Transport Protocol (RTP) for the media data. The delivery rate might be determined by a streaming server, often matching the playout rate of the data.
Some disadvantages of the “download” model may be that, due to the timing independence of the delivery and playout, either media data may not be available when it is needed for playout (for example due to the available bandwidth being less than the media data rate), causing playout to stop momentarily (“stalling”), which results in a poor user experience, or media data may be required to be downloaded very far in advance of playout (for example due to the available bandwidth being greater than the media data rate), consuming storage resources on the receiving device, which may be scarce, and consuming valuable network resources for the delivery which may be wasted if the content is not, eventually, played out or otherwise used.
An advantage of the “download” model may be that the technology needed to perform such downloads, for example HTTP, is very mature, widely deployed and applicable across a wide range of applications. Download servers and solutions for massive scalability of such file downloads (for example, HTTP Web Servers and Content Delivery Networks) may be readily available, making deployment of services based on this technology simple and low in cost.
Some disadvantages of the “streaming” model may be that generally the rate of delivery of media data is not adapted to the available bandwidth on the connection from server to client and that specialized streaming servers or more complex network architecture providing bandwidth and delay guarantees are required. Although streaming systems exist which support variation of the delivery data rate according to available bandwidth (for example Adobe Flash Adaptive Streaming), these are generally not as efficient as download transport flow control protocols such as TCP at utilizing all the available bandwidth.
Recently, new media delivery systems based on a combination of the “streaming” and “download” models have been developed and deployed. An example of such a model is referred to herein as a “block-request streaming” model, wherein a media client requests blocks of media data from serving infrastructure using a download protocol, such as HTTP. A concern in such systems may be the ability to start playing out a stream, for example decoding and rendering received audio and video streams using a personal computer and displaying the video on a computer screen and playing the audio through built in speakers, or as another example decoding and rendering received audio and video streams using a set top box and displaying the video on a television display device and playing the audio through a stereo system.
Other concerns, such as being able to decode the source blocks fast enough to keep up with the source streaming rate, to minimize the decoding latency and to reduce the use of available central processing unit (CPU) resources are issues. Another concern is to provide a robust and scalable streaming delivery solution that allows components of the system to fail without adversely affecting the quality of the streams delivered to receivers. Other problems might occur based on rapidly changing information about a presentation, as it is being distributed. Thus, it is desirable to have improved processes and apparatus.